--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Ray,
>
>
>
> I would ditch the timer as well, using a service thread to interact with the
> kflop will be much smoother.
>
>
>
> Instead of running your updates via your timer's callback you can either use
> the BackgroundWorker or an Async Delegate or parallel task if using .net4.0
>
>
>
>
>
>
>
> Parallel tasks are best because the will automagically load your cpu usage
> based on how many cores are available, etc.
>
>
>
>
>
> Background workers are pretty easy to use and have a comprehensive use
> model.
>
>
>
>
>
> Async delegates(using beginInvoke(IAsyncCallback, object) are easy to use to
> and easy to read.
>
>
>
>
>
> Whichever method you use, you will need to Invoke/Dispatch your control
> updates when using Winforms/WPF respectively.
>
>
>
>
>
> It looks like you are using winforms, so here is a quick pseudo-example
> where I am using a common method that takes an Action as a parameter and
> decides whether to invoke or not::
>
>
>
> public void UpdateDocument(Action action)
>
> {
>
> if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> coming from a thread other than the GUI
>
> {
>
> _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> thread
>
> }
>
> else
>
> {
>
> action();//Came from the same thread as the GUI, so no
> invocation required
>
> }
>
> }
>
>
>
>
>
> In the updating method of whichever threading model you chose, you can use
> the above method like so::
>
>
>
>
>
>
>
> UpdateDocument(new Action(delegate()
>
> {
>
> //Put your control updating code here.
>
> //Example:
>
> lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
>
> }));
>
>
>
>
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 3:42 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> So, I've been exercising my app on the machine, and for the most parts,
> things are working OK, though it seems a bit "sluggish" to me. For example,
> when I single-step, it takes a good 1/2 second or more to execute a line of
> G-code containing nothing more than a single comment. When running, the DROs
> update in significant increments, rather than the relatively smooth updates
> I'm accustomed to with Mach3. I'm polling status at roughly 100mSec, so I
> would expect it to appear smoother. Could still be problems in my code, so
> none of this concerns me at all at this early stage of the game.
>
> However, in working on the problem of the mis-executing DSP threads, I've
> discovered something really odd. I tested the two programs in question under
> KMotionCNC, and am satisfied the code is correct - Under KMotionCNC, they
> both execute correctly first time, every time, without fail. But, run them
> under my app, using the few lines of code posted last night, and the threads
> start, may, or may not, make the first move, then go out to lunch. KMotion
> confirms the threads remain running long after they should have terminated,
> so they seem to be stuck waiting for..... something. Now, here's the bizarre
> part - If I open KMotionCNC - I don't do anything else, just open the app -
> the thread immediately picks up and runs to completion correctly! If I just
> leave KMotionCNC running alongside my app, both DSP programs work perfectly
> every time. In addition, one of them uses a MsgBox to give a message to the
> user. If I have KMotionCNC minimized or otherwise hidden, this MsgBox does
> not appear UNTIL KMotionCNC get focus, even though the DSP thread was
> launched from MY app!
>
> What is going on here? What is KMotionCNC doing that affects my DSP programs
> in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when it did
> NOT launch the threads? Is there some buffer or FIFO somewhere that's
> filling up and blocking communications? I'm at a total loss here...
>
> Regards,
> Ray L.
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Ray,
>
>
>
> I would ditch the timer as well, using a service thread to interact with the
> kflop will be much smoother.
>
>
>
> Instead of running your updates via your timer's callback you can either use
> the BackgroundWorker or an Async Delegate or parallel task if using .net4.0
>
>
>
>
>
>
>
> Parallel tasks are best because the will automagically load your cpu usage
> based on how many cores are available, etc.
>
>
>
>
>
> Background workers are pretty easy to use and have a comprehensive use
> model.
>
>
>
>
>
> Async delegates(using beginInvoke(IAsyncCallback, object) are easy to use to
> and easy to read.
>
>
>
>
>
> Whichever method you use, you will need to Invoke/Dispatch your control
> updates when using Winforms/WPF respectively.
>
>
>
>
>
> It looks like you are using winforms, so here is a quick pseudo-example
> where I am using a common method that takes an Action as a parameter and
> decides whether to invoke or not::
>
>
>
> public void UpdateDocument(Action action)
>
> {
>
> if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> coming from a thread other than the GUI
>
> {
>
> _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> thread
>
> }
>
> else
>
> {
>
> action();//Came from the same thread as the GUI, so no
> invocation required
>
> }
>
> }
>
>
>
>
>
> In the updating method of whichever threading model you chose, you can use
> the above method like so::
>
>
>
>
>
>
>
> UpdateDocument(new Action(delegate()
>
> {
>
> //Put your control updating code here.
>
> //Example:
>
> lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
>
> }));
>
>
>
>
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 3:42 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> So, I've been exercising my app on the machine, and for the most parts,
> things are working OK, though it seems a bit "sluggish" to me. For example,
> when I single-step, it takes a good 1/2 second or more to execute a line of
> G-code containing nothing more than a single comment. When running, the DROs
> update in significant increments, rather than the relatively smooth updates
> I'm accustomed to with Mach3. I'm polling status at roughly 100mSec, so I
> would expect it to appear smoother. Could still be problems in my code, so
> none of this concerns me at all at this early stage of the game.
>
> However, in working on the problem of the mis-executing DSP threads, I've
> discovered something really odd. I tested the two programs in question under
> KMotionCNC, and am satisfied the code is correct - Under KMotionCNC, they
> both execute correctly first time, every time, without fail. But, run them
> under my app, using the few lines of code posted last night, and the threads
> start, may, or may not, make the first move, then go out to lunch. KMotion
> confirms the threads remain running long after they should have terminated,
> so they seem to be stuck waiting for..... something. Now, here's the bizarre
> part - If I open KMotionCNC - I don't do anything else, just open the app -
> the thread immediately picks up and runs to completion correctly! If I just
> leave KMotionCNC running alongside my app, both DSP programs work perfectly
> every time. In addition, one of them uses a MsgBox to give a message to the
> user. If I have KMotionCNC minimized or otherwise hidden, this MsgBox does
> not appear UNTIL KMotionCNC get focus, even though the DSP thread was
> launched from MY app!
>
> What is going on here? What is KMotionCNC doing that affects my DSP programs
> in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when it did
> NOT launch the threads? Is there some buffer or FIFO somewhere that's
> filling up and blocking communications? I'm at a total loss here...
>
> Regards,
> Ray L.
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Who you calling Gary? ;)
>
>
>
> Clarify KM"gasket" please.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 5:34 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Gary,
>
> I noted the " _GuiHost.Parent.Invoke(action)" in your example. I assume that
> could be used to push GUI updates from my KM "gasket" when something
> changes, rather than pulling them from the main app, right?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> > Ray,
> >
> >
> >
> > I would ditch the timer as well, using a service thread to interact with
> the
> > kflop will be much smoother.
> >
> >
> >
> > Instead of running your updates via your timer's callback you can either
> use
> > the BackgroundWorker or an Async Delegate or parallel task if using
> .net4.0
> >
> >
> >
> >
> >
> >
> >
> > Parallel tasks are best because the will automagically load your cpu usage
> > based on how many cores are available, etc.
> >
> >
> >
> >
> >
> > Background workers are pretty easy to use and have a comprehensive use
> > model.
> >
> >
> >
> >
> >
> > Async delegates(using beginInvoke(IAsyncCallback, object) are easy to use
> to
> > and easy to read.
> >
> >
> >
> >
> >
> > Whichever method you use, you will need to Invoke/Dispatch your control
> > updates when using Winforms/WPF respectively.
> >
> >
> >
> >
> >
> > It looks like you are using winforms, so here is a quick pseudo-example
> > where I am using a common method that takes an Action as a parameter and
> > decides whether to invoke or not::
> >
> >
> >
> > public void UpdateDocument(Action action)
> >
> > {
> >
> > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > coming from a thread other than the GUI
> >
> > {
> >
> > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > thread
> >
> > }
> >
> > else
> >
> > {
> >
> > action();//Came from the same thread as the GUI, so no
> > invocation required
> >
> > }
> >
> > }
> >
> >
> >
> >
> >
> > In the updating method of whichever threading model you chose, you can use
> > the above method like so::
> >
> >
> >
> >
> >
> >
> >
> > UpdateDocument(new Action(delegate()
> >
> > {
> >
> > //Put your control updating code here.
> >
> > //Example:
> >
> > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> >
> > }));
> >
> >
> >
> >
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 3:42 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > So, I've been exercising my app on the machine, and for the most parts,
> > things are working OK, though it seems a bit "sluggish" to me. For
> example,
> > when I single-step, it takes a good 1/2 second or more to execute a line
> of
> > G-code containing nothing more than a single comment. When running, the
> DROs
> > update in significant increments, rather than the relatively smooth
> updates
> > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec, so I
> > would expect it to appear smoother. Could still be problems in my code, so
> > none of this concerns me at all at this early stage of the game.
> >
> > However, in working on the problem of the mis-executing DSP threads, I've
> > discovered something really odd. I tested the two programs in question
> under
> > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC, they
> > both execute correctly first time, every time, without fail. But, run them
> > under my app, using the few lines of code posted last night, and the
> threads
> > start, may, or may not, make the first move, then go out to lunch. KMotion
> > confirms the threads remain running long after they should have
> terminated,
> > so they seem to be stuck waiting for..... something. Now, here's the
> bizarre
> > part - If I open KMotionCNC - I don't do anything else, just open the app
> -
> > the thread immediately picks up and runs to completion correctly! If I
> just
> > leave KMotionCNC running alongside my app, both DSP programs work
> perfectly
> > every time. In addition, one of them uses a MsgBox to give a message to
> the
> > user. If I have KMotionCNC minimized or otherwise hidden, this MsgBox does
> > not appear UNTIL KMotionCNC get focus, even though the DSP thread was
> > launched from MY app!
> >
> > What is going on here? What is KMotionCNC doing that affects my DSP
> programs
> > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when it did
> > NOT launch the threads? Is there some buffer or FIFO somewhere that's
> > filling up and blocking communications? I'm at a total loss here...
> >
> > Regards,
> > Ray L.
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Absolutely, you can push from wherever, but you will need to pass a
> reference to a control you are using(best bet is the main window) to your
> middle layer.
>
>
>
> If you used WPF you would not need to maintain a reference to any control as
> you could walk up the tree to the current Dispatcher.
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 6:14 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> Sorry - too many projects, too many people.... :-)
>
> I have a layer between my GUI and dotNet, to keep the GUI "clean" and
> high-level. All communications passes through that layer, and it also allows
> me to pull dotNet out, and replace the gasket with a simulator, to test the
> GUI stand-alone, and force all the possible states.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> > Who you calling Gary? ;)
> >
> >
> >
> > Clarify KM"gasket" please.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 5:34 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Gary,
> >
> > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I assume
> that
> > could be used to push GUI updates from my KM "gasket" when something
> > changes, rather than pulling them from the main app, right?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > > Ray,
> > >
> > >
> > >
> > > I would ditch the timer as well, using a service thread to interact with
> > the
> > > kflop will be much smoother.
> > >
> > >
> > >
> > > Instead of running your updates via your timer's callback you can either
> > use
> > > the BackgroundWorker or an Async Delegate or parallel task if using
> > .net4.0
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > Parallel tasks are best because the will automagically load your cpu
> usage
> > > based on how many cores are available, etc.
> > >
> > >
> > >
> > >
> > >
> > > Background workers are pretty easy to use and have a comprehensive use
> > > model.
> > >
> > >
> > >
> > >
> > >
> > > Async delegates(using beginInvoke(IAsyncCallback, object) are easy to
> use
> > to
> > > and easy to read.
> > >
> > >
> > >
> > >
> > >
> > > Whichever method you use, you will need to Invoke/Dispatch your control
> > > updates when using Winforms/WPF respectively.
> > >
> > >
> > >
> > >
> > >
> > > It looks like you are using winforms, so here is a quick pseudo-example
> > > where I am using a common method that takes an Action as a parameter and
> > > decides whether to invoke or not::
> > >
> > >
> > >
> > > public void UpdateDocument(Action action)
> > >
> > > {
> > >
> > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > coming from a thread other than the GUI
> > >
> > > {
> > >
> > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > thread
> > >
> > > }
> > >
> > > else
> > >
> > > {
> > >
> > > action();//Came from the same thread as the GUI, so no
> > > invocation required
> > >
> > > }
> > >
> > > }
> > >
> > >
> > >
> > >
> > >
> > > In the updating method of whichever threading model you chose, you can
> use
> > > the above method like so::
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > UpdateDocument(new Action(delegate()
> > >
> > > {
> > >
> > > //Put your control updating code here.
> > >
> > > //Example:
> > >
> > > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> > >
> > > }));
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > So, I've been exercising my app on the machine, and for the most parts,
> > > things are working OK, though it seems a bit "sluggish" to me. For
> > example,
> > > when I single-step, it takes a good 1/2 second or more to execute a line
> > of
> > > G-code containing nothing more than a single comment. When running, the
> > DROs
> > > update in significant increments, rather than the relatively smooth
> > updates
> > > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec, so
> I
> > > would expect it to appear smoother. Could still be problems in my code,
> so
> > > none of this concerns me at all at this early stage of the game.
> > >
> > > However, in working on the problem of the mis-executing DSP threads,
> I've
> > > discovered something really odd. I tested the two programs in question
> > under
> > > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC,
> they
> > > both execute correctly first time, every time, without fail. But, run
> them
> > > under my app, using the few lines of code posted last night, and the
> > threads
> > > start, may, or may not, make the first move, then go out to lunch.
> KMotion
> > > confirms the threads remain running long after they should have
> > terminated,
> > > so they seem to be stuck waiting for..... something. Now, here's the
> > bizarre
> > > part - If I open KMotionCNC - I don't do anything else, just open the
> app
> > -
> > > the thread immediately picks up and runs to completion correctly! If I
> > just
> > > leave KMotionCNC running alongside my app, both DSP programs work
> > perfectly
> > > every time. In addition, one of them uses a MsgBox to give a message to
> > the
> > > user. If I have KMotionCNC minimized or otherwise hidden, this MsgBox
> does
> > > not appear UNTIL KMotionCNC get focus, even though the DSP thread was
> > > launched from MY app!
> > >
> > > What is going on here? What is KMotionCNC doing that affects my DSP
> > programs
> > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when it
> did
> > > NOT launch the threads? Is there some buffer or FIFO somewhere that's
> > > filling up and blocking communications? I'm at a total loss here...
> > >
> > > Regards,
> > > Ray L.
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
>
> First off, you never want to have too many threads running, technically you
> can only have one run per core and anything after that is going to be time
> slicing.
>
>
>
>
>
> If I was making a small lightweight winforms app in .net3.5(like the HTML
> controller ;-) ), I would/am use/ing the invoke methods I outlined earlier.
>
>
>
> Inside of it, I basically have an endless loop running on a separate
> worker thread using the simple BackgroundWorker class. The endless loop
> sleeps every 100ms and I have the DRO's updating on that time slice. Within
> the loop I also have a counter that I increment/reset every 5 cycles and
> when that happens I update the less important items.
>
>
>
> Very basic setup that only uses one additional thread that updates the DRO's
> 1/10th a second and then things like LED's, enable status, etc… get updated
> every ½ a second.
>
>
>
> I will re-upload my source so you can see how it works.
>
>
>
> -Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 6:49 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> I'm not changing to WPF at this late stage of the game! :-)
>
> I can see how I could use parallel threads to make the display updates more
> efficient (launch separate threads to update all the DROs, and other
> controls). I assume the wonders of .NET will deal with all the concurrency
> issues that could create in accessing especially dotNet objects? I just
> checked and my update loop is running only about 5X/second right now, though
> GUI response is generally not bad. It's mostly the DRO updates that really
> need to be sped up.
>
> How would you do it?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> > Absolutely, you can push from wherever, but you will need to pass a
> > reference to a control you are using(best bet is the main window) to your
> > middle layer.
> >
> >
> >
> > If you used WPF you would not need to maintain a reference to any control
> as
> > you could walk up the tree to the current Dispatcher.
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 6:14 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > Sorry - too many projects, too many people.... :-)
> >
> > I have a layer between my GUI and dotNet, to keep the GUI "clean" and
> > high-level. All communications passes through that layer, and it also
> allows
> > me to pull dotNet out, and replace the gasket with a simulator, to test
> the
> > GUI stand-alone, and force all the possible states.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > > Who you calling Gary? ;)
> > >
> > >
> > >
> > > Clarify KM"gasket" please.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Gary,
> > >
> > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I assume
> > that
> > > could be used to push GUI updates from my KM "gasket" when something
> > > changes, rather than pulling them from the main app, right?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Ray,
> > > >
> > > >
> > > >
> > > > I would ditch the timer as well, using a service thread to interact
> with
> > > the
> > > > kflop will be much smoother.
> > > >
> > > >
> > > >
> > > > Instead of running your updates via your timer's callback you can
> either
> > > use
> > > > the BackgroundWorker or an Async Delegate or parallel task if using
> > > .net4.0
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Parallel tasks are best because the will automagically load your cpu
> > usage
> > > > based on how many cores are available, etc.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Background workers are pretty easy to use and have a comprehensive use
> > > > model.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Async delegates(using beginInvoke(IAsyncCallback, object) are easy to
> > use
> > > to
> > > > and easy to read.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Whichever method you use, you will need to Invoke/Dispatch your
> control
> > > > updates when using Winforms/WPF respectively.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > It looks like you are using winforms, so here is a quick
> pseudo-example
> > > > where I am using a common method that takes an Action as a parameter
> and
> > > > decides whether to invoke or not::
> > > >
> > > >
> > > >
> > > > public void UpdateDocument(Action action)
> > > >
> > > > {
> > > >
> > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > > coming from a thread other than the GUI
> > > >
> > > > {
> > > >
> > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > thread
> > > >
> > > > }
> > > >
> > > > else
> > > >
> > > > {
> > > >
> > > > action();//Came from the same thread as the GUI, so no
> > > > invocation required
> > > >
> > > > }
> > > >
> > > > }
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > In the updating method of whichever threading model you chose, you can
> > use
> > > > the above method like so::
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > UpdateDocument(new Action(delegate()
> > > >
> > > > {
> > > >
> > > > //Put your control updating code here.
> > > >
> > > > //Example:
> > > >
> > > > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> > > >
> > > > }));
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > So, I've been exercising my app on the machine, and for the most
> parts,
> > > > things are working OK, though it seems a bit "sluggish" to me. For
> > > example,
> > > > when I single-step, it takes a good 1/2 second or more to execute a
> line
> > > of
> > > > G-code containing nothing more than a single comment. When running,
> the
> > > DROs
> > > > update in significant increments, rather than the relatively smooth
> > > updates
> > > > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec,
> so
> > I
> > > > would expect it to appear smoother. Could still be problems in my
> code,
> > so
> > > > none of this concerns me at all at this early stage of the game.
> > > >
> > > > However, in working on the problem of the mis-executing DSP threads,
> > I've
> > > > discovered something really odd. I tested the two programs in question
> > > under
> > > > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC,
> > they
> > > > both execute correctly first time, every time, without fail. But, run
> > them
> > > > under my app, using the few lines of code posted last night, and the
> > > threads
> > > > start, may, or may not, make the first move, then go out to lunch.
> > KMotion
> > > > confirms the threads remain running long after they should have
> > > terminated,
> > > > so they seem to be stuck waiting for..... something. Now, here's the
> > > bizarre
> > > > part - If I open KMotionCNC - I don't do anything else, just open the
> > app
> > > -
> > > > the thread immediately picks up and runs to completion correctly! If I
> > > just
> > > > leave KMotionCNC running alongside my app, both DSP programs work
> > > perfectly
> > > > every time. In addition, one of them uses a MsgBox to give a message
> to
> > > the
> > > > user. If I have KMotionCNC minimized or otherwise hidden, this MsgBox
> > does
> > > > not appear UNTIL KMotionCNC get focus, even though the DSP thread was
> > > > launched from MY app!
> > > >
> > > > What is going on here? What is KMotionCNC doing that affects my DSP
> > > programs
> > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when it
> > did
> > > > NOT launch the threads? Is there some buffer or FIFO somewhere that's
> > > > filling up and blocking communications? I'm at a total loss here...
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> The only thing I will add at this point is try it and you will see.
>
>
>
>
>
> I will add that MM uses a multi-threading model, has a lot more rendering
> going on that a winforms app, also does openGL toolpath display and I can
> see out to 4-5 decimals changing smoothly during feed moves.
>
>
>
>
>
> Nowadays any non-trivial app requires multi-threading.
>
>
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 8:59 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> Here's where I keep getting stuck - I believe the bulk of the display update
> time is getting the information from dotNet, not actually updating the
> controls. I already update the DROs more often than the other controls, by
> just doing the DROs on every timer tick, and the others on alternate ticks.
> How will another thread improve performance, if the bottleneck is getting
> the update data (which comes primarily from MainStatus), particularly since
> I have to go through an invoke to modify each control?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> >
> > First off, you never want to have too many threads running, technically
> you
> > can only have one run per core and anything after that is going to be time
> > slicing.
> >
> >
> >
> >
> >
> > If I was making a small lightweight winforms app in .net3.5(like the HTML
> > controller ;-) ), I would/am use/ing the invoke methods I outlined
> earlier.
> >
> >
> >
> > Inside of it, I basically have an endless loop running on a separate
> > worker thread using the simple BackgroundWorker class. The endless loop
> > sleeps every 100ms and I have the DRO's updating on that time slice.
> Within
> > the loop I also have a counter that I increment/reset every 5 cycles and
> > when that happens I update the less important items.
> >
> >
> >
> > Very basic setup that only uses one additional thread that updates the
> DRO's
> > 1/10th a second and then things like LED's, enable status, etc… get
> updated
> > every ½ a second.
> >
> >
> >
> > I will re-upload my source so you can see how it works.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 6:49 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > I'm not changing to WPF at this late stage of the game! :-)
> >
> > I can see how I could use parallel threads to make the display updates
> more
> > efficient (launch separate threads to update all the DROs, and other
> > controls). I assume the wonders of .NET will deal with all the concurrency
> > issues that could create in accessing especially dotNet objects? I just
> > checked and my update loop is running only about 5X/second right now,
> though
> > GUI response is generally not bad. It's mostly the DRO updates that really
> > need to be sped up.
> >
> > How would you do it?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > > Absolutely, you can push from wherever, but you will need to pass a
> > > reference to a control you are using(best bet is the main window) to
> your
> > > middle layer.
> > >
> > >
> > >
> > > If you used WPF you would not need to maintain a reference to any
> control
> > as
> > > you could walk up the tree to the current Dispatcher.
> > >
> > >
> > >
> > > -Brad
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > Sorry - too many projects, too many people.... :-)
> > >
> > > I have a layer between my GUI and dotNet, to keep the GUI "clean" and
> > > high-level. All communications passes through that layer, and it also
> > allows
> > > me to pull dotNet out, and replace the gasket with a simulator, to test
> > the
> > > GUI stand-alone, and force all the possible states.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Who you calling Gary? ;)
> > > >
> > > >
> > > >
> > > > Clarify KM"gasket" please.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Gary,
> > > >
> > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> assume
> > > that
> > > > could be used to push GUI updates from my KM "gasket" when something
> > > > changes, rather than pulling them from the main app, right?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Ray,
> > > > >
> > > > >
> > > > >
> > > > > I would ditch the timer as well, using a service thread to interact
> > with
> > > > the
> > > > > kflop will be much smoother.
> > > > >
> > > > >
> > > > >
> > > > > Instead of running your updates via your timer's callback you can
> > either
> > > > use
> > > > > the BackgroundWorker or an Async Delegate or parallel task if using
> > > > .net4.0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Parallel tasks are best because the will automagically load your cpu
> > > usage
> > > > > based on how many cores are available, etc.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Background workers are pretty easy to use and have a comprehensive
> use
> > > > > model.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are easy
> to
> > > use
> > > > to
> > > > > and easy to read.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Whichever method you use, you will need to Invoke/Dispatch your
> > control
> > > > > updates when using Winforms/WPF respectively.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It looks like you are using winforms, so here is a quick
> > pseudo-example
> > > > > where I am using a common method that takes an Action as a parameter
> > and
> > > > > decides whether to invoke or not::
> > > > >
> > > > >
> > > > >
> > > > > public void UpdateDocument(Action action)
> > > > >
> > > > > {
> > > > >
> > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > > > coming from a thread other than the GUI
> > > > >
> > > > > {
> > > > >
> > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > thread
> > > > >
> > > > > }
> > > > >
> > > > > else
> > > > >
> > > > > {
> > > > >
> > > > > action();//Came from the same thread as the GUI, so no
> > > > > invocation required
> > > > >
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > In the updating method of whichever threading model you chose, you
> can
> > > use
> > > > > the above method like so::
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > UpdateDocument(new Action(delegate()
> > > > >
> > > > > {
> > > > >
> > > > > //Put your control updating code here.
> > > > >
> > > > > //Example:
> > > > >
> > > > > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> > > > >
> > > > > }));
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > So, I've been exercising my app on the machine, and for the most
> > parts,
> > > > > things are working OK, though it seems a bit "sluggish" to me. For
> > > > example,
> > > > > when I single-step, it takes a good 1/2 second or more to execute a
> > line
> > > > of
> > > > > G-code containing nothing more than a single comment. When running,
> > the
> > > > DROs
> > > > > update in significant increments, rather than the relatively smooth
> > > > updates
> > > > > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec,
> > so
> > > I
> > > > > would expect it to appear smoother. Could still be problems in my
> > code,
> > > so
> > > > > none of this concerns me at all at this early stage of the game.
> > > > >
> > > > > However, in working on the problem of the mis-executing DSP threads,
> > > I've
> > > > > discovered something really odd. I tested the two programs in
> question
> > > > under
> > > > > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC,
> > > they
> > > > > both execute correctly first time, every time, without fail. But,
> run
> > > them
> > > > > under my app, using the few lines of code posted last night, and the
> > > > threads
> > > > > start, may, or may not, make the first move, then go out to lunch.
> > > KMotion
> > > > > confirms the threads remain running long after they should have
> > > > terminated,
> > > > > so they seem to be stuck waiting for..... something. Now, here's the
> > > > bizarre
> > > > > part - If I open KMotionCNC - I don't do anything else, just open
> the
> > > app
> > > > -
> > > > > the thread immediately picks up and runs to completion correctly! If
> I
> > > > just
> > > > > leave KMotionCNC running alongside my app, both DSP programs work
> > > > perfectly
> > > > > every time. In addition, one of them uses a MsgBox to give a message
> > to
> > > > the
> > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> MsgBox
> > > does
> > > > > not appear UNTIL KMotionCNC get focus, even though the DSP thread
> was
> > > > > launched from MY app!
> > > > >
> > > > > What is going on here? What is KMotionCNC doing that affects my DSP
> > > > programs
> > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when
> it
> > > did
> > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> that's
> > > > > filling up and blocking communications? I'm at a total loss here...
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> The only thing I will add at this point is try it and you will see.
>
>
>
>
>
> I will add that MM uses a multi-threading model, has a lot more rendering
> going on that a winforms app, also does openGL toolpath display and I can
> see out to 4-5 decimals changing smoothly during feed moves.
>
>
>
>
>
> Nowadays any non-trivial app requires multi-threading.
>
>
>
>
>
> -Brad
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Wednesday, January 25, 2012 8:59 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> Here's where I keep getting stuck - I believe the bulk of the display update
> time is getting the information from dotNet, not actually updating the
> controls. I already update the DROs more often than the other controls, by
> just doing the DROs on every timer tick, and the others on alternate ticks.
> How will another thread improve performance, if the bottleneck is getting
> the update data (which comes primarily from MainStatus), particularly since
> I have to go through an invoke to modify each control?
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> >
> > First off, you never want to have too many threads running, technically
> you
> > can only have one run per core and anything after that is going to be time
> > slicing.
> >
> >
> >
> >
> >
> > If I was making a small lightweight winforms app in .net3.5(like the HTML
> > controller ;-) ), I would/am use/ing the invoke methods I outlined
> earlier.
> >
> >
> >
> > Inside of it, I basically have an endless loop running on a separate
> > worker thread using the simple BackgroundWorker class. The endless loop
> > sleeps every 100ms and I have the DRO's updating on that time slice.
> Within
> > the loop I also have a counter that I increment/reset every 5 cycles and
> > when that happens I update the less important items.
> >
> >
> >
> > Very basic setup that only uses one additional thread that updates the
> DRO's
> > 1/10th a second and then things like LED's, enable status, etc… get
> updated
> > every ½ a second.
> >
> >
> >
> > I will re-upload my source so you can see how it works.
> >
> >
> >
> > -Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 6:49 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > I'm not changing to WPF at this late stage of the game! :-)
> >
> > I can see how I could use parallel threads to make the display updates
> more
> > efficient (launch separate threads to update all the DROs, and other
> > controls). I assume the wonders of .NET will deal with all the concurrency
> > issues that could create in accessing especially dotNet objects? I just
> > checked and my update loop is running only about 5X/second right now,
> though
> > GUI response is generally not bad. It's mostly the DRO updates that really
> > need to be sped up.
> >
> > How would you do it?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > > Absolutely, you can push from wherever, but you will need to pass a
> > > reference to a control you are using(best bet is the main window) to
> your
> > > middle layer.
> > >
> > >
> > >
> > > If you used WPF you would not need to maintain a reference to any
> control
> > as
> > > you could walk up the tree to the current Dispatcher.
> > >
> > >
> > >
> > > -Brad
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > Sorry - too many projects, too many people.... :-)
> > >
> > > I have a layer between my GUI and dotNet, to keep the GUI "clean" and
> > > high-level. All communications passes through that layer, and it also
> > allows
> > > me to pull dotNet out, and replace the gasket with a simulator, to test
> > the
> > > GUI stand-alone, and force all the possible states.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Who you calling Gary? ;)
> > > >
> > > >
> > > >
> > > > Clarify KM"gasket" please.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Gary,
> > > >
> > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> assume
> > > that
> > > > could be used to push GUI updates from my KM "gasket" when something
> > > > changes, rather than pulling them from the main app, right?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Ray,
> > > > >
> > > > >
> > > > >
> > > > > I would ditch the timer as well, using a service thread to interact
> > with
> > > > the
> > > > > kflop will be much smoother.
> > > > >
> > > > >
> > > > >
> > > > > Instead of running your updates via your timer's callback you can
> > either
> > > > use
> > > > > the BackgroundWorker or an Async Delegate or parallel task if using
> > > > .net4.0
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Parallel tasks are best because the will automagically load your cpu
> > > usage
> > > > > based on how many cores are available, etc.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Background workers are pretty easy to use and have a comprehensive
> use
> > > > > model.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are easy
> to
> > > use
> > > > to
> > > > > and easy to read.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Whichever method you use, you will need to Invoke/Dispatch your
> > control
> > > > > updates when using Winforms/WPF respectively.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > It looks like you are using winforms, so here is a quick
> > pseudo-example
> > > > > where I am using a common method that takes an Action as a parameter
> > and
> > > > > decides whether to invoke or not::
> > > > >
> > > > >
> > > > >
> > > > > public void UpdateDocument(Action action)
> > > > >
> > > > > {
> > > > >
> > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > > > coming from a thread other than the GUI
> > > > >
> > > > > {
> > > > >
> > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > thread
> > > > >
> > > > > }
> > > > >
> > > > > else
> > > > >
> > > > > {
> > > > >
> > > > > action();//Came from the same thread as the GUI, so no
> > > > > invocation required
> > > > >
> > > > > }
> > > > >
> > > > > }
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > In the updating method of whichever threading model you chose, you
> can
> > > use
> > > > > the above method like so::
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > UpdateDocument(new Action(delegate()
> > > > >
> > > > > {
> > > > >
> > > > > //Put your control updating code here.
> > > > >
> > > > > //Example:
> > > > >
> > > > > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> > > > >
> > > > > }));
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > So, I've been exercising my app on the machine, and for the most
> > parts,
> > > > > things are working OK, though it seems a bit "sluggish" to me. For
> > > > example,
> > > > > when I single-step, it takes a good 1/2 second or more to execute a
> > line
> > > > of
> > > > > G-code containing nothing more than a single comment. When running,
> > the
> > > > DROs
> > > > > update in significant increments, rather than the relatively smooth
> > > > updates
> > > > > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec,
> > so
> > > I
> > > > > would expect it to appear smoother. Could still be problems in my
> > code,
> > > so
> > > > > none of this concerns me at all at this early stage of the game.
> > > > >
> > > > > However, in working on the problem of the mis-executing DSP threads,
> > > I've
> > > > > discovered something really odd. I tested the two programs in
> question
> > > > under
> > > > > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC,
> > > they
> > > > > both execute correctly first time, every time, without fail. But,
> run
> > > them
> > > > > under my app, using the few lines of code posted last night, and the
> > > > threads
> > > > > start, may, or may not, make the first move, then go out to lunch.
> > > KMotion
> > > > > confirms the threads remain running long after they should have
> > > > terminated,
> > > > > so they seem to be stuck waiting for..... something. Now, here's the
> > > > bizarre
> > > > > part - If I open KMotionCNC - I don't do anything else, just open
> the
> > > app
> > > > -
> > > > > the thread immediately picks up and runs to completion correctly! If
> I
> > > > just
> > > > > leave KMotionCNC running alongside my app, both DSP programs work
> > > > perfectly
> > > > > every time. In addition, one of them uses a MsgBox to give a message
> > to
> > > > the
> > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> MsgBox
> > > does
> > > > > not appear UNTIL KMotionCNC get focus, even though the DSP thread
> was
> > > > > launched from MY app!
> > > > >
> > > > > What is going on here? What is KMotionCNC doing that affects my DSP
> > > > programs
> > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when
> it
> > > did
> > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> that's
> > > > > filling up and blocking communications? I'm at a total loss here...
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> Well, I moved the display updates to a BackgroundWorker thread by plagiarizing what you do in your HTML app. It was relatively painless, but, surprisingly, didn't really make any perceptible difference in terms of display update performance. It also, not surprisingly, introduced a couple of minor bugs. I have yet to get it to reliably close cleanly. On the FormClosing event, I do a CancelAsync, followed by a Sleep(250), but I still sometimes get a null reference error in UpdateDocument when Dispose is called. Not sure I understand why that's happening.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > The only thing I will add at this point is try it and you will see.
> >
> >
> >
> >
> >
> > I will add that MM uses a multi-threading model, has a lot more rendering
> > going on that a winforms app, also does openGL toolpath display and I can
> > see out to 4-5 decimals changing smoothly during feed moves.
> >
> >
> >
> >
> >
> > Nowadays any non-trivial app requires multi-threading.
> >
> >
> >
> >
> >
> > -Brad
> >
> >
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Wednesday, January 25, 2012 8:59 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > Here's where I keep getting stuck - I believe the bulk of the display update
> > time is getting the information from dotNet, not actually updating the
> > controls. I already update the DROs more often than the other controls, by
> > just doing the DROs on every timer tick, and the others on alternate ticks.
> > How will another thread improve performance, if the bottleneck is getting
> > the update data (which comes primarily from MainStatus), particularly since
> > I have to go through an invoke to modify each control?
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > >
> > > First off, you never want to have too many threads running, technically
> > you
> > > can only have one run per core and anything after that is going to be time
> > > slicing.
> > >
> > >
> > >
> > >
> > >
> > > If I was making a small lightweight winforms app in .net3.5(like the HTML
> > > controller ;-) ), I would/am use/ing the invoke methods I outlined
> > earlier.
> > >
> > >
> > >
> > > Inside of it, I basically have an endless loop running on a separate
> > > worker thread using the simple BackgroundWorker class. The endless loop
> > > sleeps every 100ms and I have the DRO's updating on that time slice.
> > Within
> > > the loop I also have a counter that I increment/reset every 5 cycles and
> > > when that happens I update the less important items.
> > >
> > >
> > >
> > > Very basic setup that only uses one additional thread that updates the
> > DRO's
> > > 1/10th a second and then things like LED's, enable status, etc… get
> > updated
> > > every ½ a second.
> > >
> > >
> > >
> > > I will re-upload my source so you can see how it works.
> > >
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 6:49 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > I'm not changing to WPF at this late stage of the game! :-)
> > >
> > > I can see how I could use parallel threads to make the display updates
> > more
> > > efficient (launch separate threads to update all the DROs, and other
> > > controls). I assume the wonders of .NET will deal with all the concurrency
> > > issues that could create in accessing especially dotNet objects? I just
> > > checked and my update loop is running only about 5X/second right now,
> > though
> > > GUI response is generally not bad. It's mostly the DRO updates that really
> > > need to be sped up.
> > >
> > > How would you do it?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > > Absolutely, you can push from wherever, but you will need to pass a
> > > > reference to a control you are using(best bet is the main window) to
> > your
> > > > middle layer.
> > > >
> > > >
> > > >
> > > > If you used WPF you would not need to maintain a reference to any
> > control
> > > as
> > > > you could walk up the tree to the current Dispatcher.
> > > >
> > > >
> > > >
> > > > -Brad
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > Sorry - too many projects, too many people.... :-)
> > > >
> > > > I have a layer between my GUI and dotNet, to keep the GUI "clean" and
> > > > high-level. All communications passes through that layer, and it also
> > > allows
> > > > me to pull dotNet out, and replace the gasket with a simulator, to test
> > > the
> > > > GUI stand-alone, and force all the possible states.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Who you calling Gary? ;)
> > > > >
> > > > >
> > > > >
> > > > > Clarify KM"gasket" please.
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Gary,
> > > > >
> > > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> > assume
> > > > that
> > > > > could be used to push GUI updates from my KM "gasket" when something
> > > > > changes, rather than pulling them from the main app, right?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > Ray,
> > > > > >
> > > > > >
> > > > > >
> > > > > > I would ditch the timer as well, using a service thread to interact
> > > with
> > > > > the
> > > > > > kflop will be much smoother.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Instead of running your updates via your timer's callback you can
> > > either
> > > > > use
> > > > > > the BackgroundWorker or an Async Delegate or parallel task if using
> > > > > .net4.0
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Parallel tasks are best because the will automagically load your cpu
> > > > usage
> > > > > > based on how many cores are available, etc.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Background workers are pretty easy to use and have a comprehensive
> > use
> > > > > > model.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are easy
> > to
> > > > use
> > > > > to
> > > > > > and easy to read.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Whichever method you use, you will need to Invoke/Dispatch your
> > > control
> > > > > > updates when using Winforms/WPF respectively.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > It looks like you are using winforms, so here is a quick
> > > pseudo-example
> > > > > > where I am using a common method that takes an Action as a parameter
> > > and
> > > > > > decides whether to invoke or not::
> > > > > >
> > > > > >
> > > > > >
> > > > > > public void UpdateDocument(Action action)
> > > > > >
> > > > > > {
> > > > > >
> > > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > > > > coming from a thread other than the GUI
> > > > > >
> > > > > > {
> > > > > >
> > > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > > thread
> > > > > >
> > > > > > }
> > > > > >
> > > > > > else
> > > > > >
> > > > > > {
> > > > > >
> > > > > > action();//Came from the same thread as the GUI, so no
> > > > > > invocation required
> > > > > >
> > > > > > }
> > > > > >
> > > > > > }
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > In the updating method of whichever threading model you chose, you
> > can
> > > > use
> > > > > > the above method like so::
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > UpdateDocument(new Action(delegate()
> > > > > >
> > > > > > {
> > > > > >
> > > > > > //Put your control updating code here.
> > > > > >
> > > > > > //Example:
> > > > > >
> > > > > > lblXaxisDest.Text = _AxisContainer["X"].ActualPosition.ToString();
> > > > > >
> > > > > > }));
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > On
> > > > > > Behalf Of himykabibble
> > > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > So, I've been exercising my app on the machine, and for the most
> > > parts,
> > > > > > things are working OK, though it seems a bit "sluggish" to me. For
> > > > > example,
> > > > > > when I single-step, it takes a good 1/2 second or more to execute a
> > > line
> > > > > of
> > > > > > G-code containing nothing more than a single comment. When running,
> > > the
> > > > > DROs
> > > > > > update in significant increments, rather than the relatively smooth
> > > > > updates
> > > > > > I'm accustomed to with Mach3. I'm polling status at roughly 100mSec,
> > > so
> > > > I
> > > > > > would expect it to appear smoother. Could still be problems in my
> > > code,
> > > > so
> > > > > > none of this concerns me at all at this early stage of the game.
> > > > > >
> > > > > > However, in working on the problem of the mis-executing DSP threads,
> > > > I've
> > > > > > discovered something really odd. I tested the two programs in
> > question
> > > > > under
> > > > > > KMotionCNC, and am satisfied the code is correct - Under KMotionCNC,
> > > > they
> > > > > > both execute correctly first time, every time, without fail. But,
> > run
> > > > them
> > > > > > under my app, using the few lines of code posted last night, and the
> > > > > threads
> > > > > > start, may, or may not, make the first move, then go out to lunch.
> > > > KMotion
> > > > > > confirms the threads remain running long after they should have
> > > > > terminated,
> > > > > > so they seem to be stuck waiting for..... something. Now, here's the
> > > > > bizarre
> > > > > > part - If I open KMotionCNC - I don't do anything else, just open
> > the
> > > > app
> > > > > -
> > > > > > the thread immediately picks up and runs to completion correctly! If
> > I
> > > > > just
> > > > > > leave KMotionCNC running alongside my app, both DSP programs work
> > > > > perfectly
> > > > > > every time. In addition, one of them uses a MsgBox to give a message
> > > to
> > > > > the
> > > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> > MsgBox
> > > > does
> > > > > > not appear UNTIL KMotionCNC get focus, even though the DSP thread
> > was
> > > > > > launched from MY app!
> > > > > >
> > > > > > What is going on here? What is KMotionCNC doing that affects my DSP
> > > > > programs
> > > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC, when
> > it
> > > > did
> > > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> > that's
> > > > > > filling up and blocking communications? I'm at a total loss here...
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Hello Ray,
>
>
>
> I would probably need to see some code to be much help.
>
>
>
> Brad Murry
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Thursday, January 26, 2012 8:57 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> I've got this working pretty well now, with a few exceptions. But I'm not
> clear on the right way to handle communications with dotNet. My UI update
> thread needs to access various dotNet data to create the updates. Right now,
> I'm doing those accesses in the DoWork method, creating an object that
> contains the UI status, then tossing that over to the UI thread to update
> the controls. But, the UI thread also needs to access dotNet when things
> like button events occur. Should I push ALL dotNet accesses to the UI
> thread? Or is there a better way?
>
> Right now, something I've done has made the hangs much worse. I'm getting
> pretty regular hangs in the DLL, without disconnects, and also can't seem to
> get the BackgroundWorker thread to exit. It stops updating the display, but
> doesn't exit.
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "himykabibble" <jagboy@> wrote:
> >
> > Brad,
> >
> > Well, I moved the display updates to a BackgroundWorker thread by
> plagiarizing what you do in your HTML app. It was relatively painless, but,
> surprisingly, didn't really make any perceptible difference in terms of
> display update performance. It also, not surprisingly, introduced a couple
> of minor bugs. I have yet to get it to reliably close cleanly. On the
> FormClosing event, I do a CancelAsync, followed by a Sleep(250), but I still
> sometimes get a null reference error in UpdateDocument when Dispose is
> called. Not sure I understand why that's happening.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> > >
> > > The only thing I will add at this point is try it and you will see.
> > >
> > >
> > >
> > >
> > >
> > > I will add that MM uses a multi-threading model, has a lot more
> rendering
> > > going on that a winforms app, also does openGL toolpath display and I
> can
> > > see out to 4-5 decimals changing smoothly during feed moves.
> > >
> > >
> > >
> > >
> > >
> > > Nowadays any non-trivial app requires multi-threading.
> > >
> > >
> > >
> > >
> > >
> > > -Brad
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > > Behalf Of himykabibble
> > > Sent: Wednesday, January 25, 2012 8:59 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > Here's where I keep getting stuck - I believe the bulk of the display
> update
> > > time is getting the information from dotNet, not actually updating the
> > > controls. I already update the DROs more often than the other controls,
> by
> > > just doing the DROs on every timer tick, and the others on alternate
> ticks.
> > > How will another thread improve performance, if the bottleneck is
> getting
> > > the update data (which comes primarily from MainStatus), particularly
> since
> > > I have to go through an invoke to modify each control?
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > >
> > > >
> > > > First off, you never want to have too many threads running,
> technically
> > > you
> > > > can only have one run per core and anything after that is going to be
> time
> > > > slicing.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > If I was making a small lightweight winforms app in .net3.5(like the
> HTML
> > > > controller ;-) ), I would/am use/ing the invoke methods I outlined
> > > earlier.
> > > >
> > > >
> > > >
> > > > Inside of it, I basically have an endless loop running on a separate
> > > > worker thread using the simple BackgroundWorker class. The endless
> loop
> > > > sleeps every 100ms and I have the DRO's updating on that time slice.
> > > Within
> > > > the loop I also have a counter that I increment/reset every 5 cycles
> and
> > > > when that happens I update the less important items.
> > > >
> > > >
> > > >
> > > > Very basic setup that only uses one additional thread that updates the
> > > DRO's
> > > > 1/10th a second and then things like LED's, enable status, etc… get
> > > updated
> > > > every ½ a second.
> > > >
> > > >
> > > >
> > > > I will re-upload my source so you can see how it works.
> > > >
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 6:49 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > I'm not changing to WPF at this late stage of the game! :-)
> > > >
> > > > I can see how I could use parallel threads to make the display updates
> > > more
> > > > efficient (launch separate threads to update all the DROs, and other
> > > > controls). I assume the wonders of .NET will deal with all the
> concurrency
> > > > issues that could create in accessing especially dotNet objects? I
> just
> > > > checked and my update loop is running only about 5X/second right now,
> > > though
> > > > GUI response is generally not bad. It's mostly the DRO updates that
> really
> > > > need to be sped up.
> > > >
> > > > How would you do it?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > Absolutely, you can push from wherever, but you will need to pass a
> > > > > reference to a control you are using(best bet is the main window) to
> > > your
> > > > > middle layer.
> > > > >
> > > > >
> > > > >
> > > > > If you used WPF you would not need to maintain a reference to any
> > > control
> > > > as
> > > > > you could walk up the tree to the current Dispatcher.
> > > > >
> > > > >
> > > > >
> > > > > -Brad
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > Sorry - too many projects, too many people.... :-)
> > > > >
> > > > > I have a layer between my GUI and dotNet, to keep the GUI "clean"
> and
> > > > > high-level. All communications passes through that layer, and it
> also
> > > > allows
> > > > > me to pull dotNet out, and replace the gasket with a simulator, to
> test
> > > > the
> > > > > GUI stand-alone, and force all the possible states.
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > Who you calling Gary? ;)
> > > > > >
> > > > > >
> > > > > >
> > > > > > Clarify KM"gasket" please.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > On
> > > > > > Behalf Of himykabibble
> > > > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Gary,
> > > > > >
> > > > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> > > assume
> > > > > that
> > > > > > could be used to push GUI updates from my KM "gasket" when
> something
> > > > > > changes, rather than pulling them from the main app, right?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > >
> > > > > > > Ray,
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > I would ditch the timer as well, using a service thread to
> interact
> > > > with
> > > > > > the
> > > > > > > kflop will be much smoother.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Instead of running your updates via your timer's callback you
> can
> > > > either
> > > > > > use
> > > > > > > the BackgroundWorker or an Async Delegate or parallel task if
> using
> > > > > > .net4.0
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Parallel tasks are best because the will automagically load your
> cpu
> > > > > usage
> > > > > > > based on how many cores are available, etc.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Background workers are pretty easy to use and have a
> comprehensive
> > > use
> > > > > > > model.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are
> easy
> > > to
> > > > > use
> > > > > > to
> > > > > > > and easy to read.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Whichever method you use, you will need to Invoke/Dispatch your
> > > > control
> > > > > > > updates when using Winforms/WPF respectively.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > It looks like you are using winforms, so here is a quick
> > > > pseudo-example
> > > > > > > where I am using a common method that takes an Action as a
> parameter
> > > > and
> > > > > > > decides whether to invoke or not::
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > public void UpdateDocument(Action action)
> > > > > > >
> > > > > > > {
> > > > > > >
> > > > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call is
> > > > > > > coming from a thread other than the GUI
> > > > > > >
> > > > > > > {
> > > > > > >
> > > > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > > > thread
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > > else
> > > > > > >
> > > > > > > {
> > > > > > >
> > > > > > > action();//Came from the same thread as the GUI, so no
> > > > > > > invocation required
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > > }
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > In the updating method of whichever threading model you chose,
> you
> > > can
> > > > > use
> > > > > > > the above method like so::
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > UpdateDocument(new Action(delegate()
> > > > > > >
> > > > > > > {
> > > > > > >
> > > > > > > //Put your control updating code here.
> > > > > > >
> > > > > > > //Example:
> > > > > > >
> > > > > > > lblXaxisDest.Text =
> _AxisContainer["X"].ActualPosition.ToString();
> > > > > > >
> > > > > > > }));
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > On
> > > > > > > Behalf Of himykabibble
> > > > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > So, I've been exercising my app on the machine, and for the most
> > > > parts,
> > > > > > > things are working OK, though it seems a bit "sluggish" to me.
> For
> > > > > > example,
> > > > > > > when I single-step, it takes a good 1/2 second or more to
> execute a
> > > > line
> > > > > > of
> > > > > > > G-code containing nothing more than a single comment. When
> running,
> > > > the
> > > > > > DROs
> > > > > > > update in significant increments, rather than the relatively
> smooth
> > > > > > updates
> > > > > > > I'm accustomed to with Mach3. I'm polling status at roughly
> 100mSec,
> > > > so
> > > > > I
> > > > > > > would expect it to appear smoother. Could still be problems in
> my
> > > > code,
> > > > > so
> > > > > > > none of this concerns me at all at this early stage of the game.
> > > > > > >
> > > > > > > However, in working on the problem of the mis-executing DSP
> threads,
> > > > > I've
> > > > > > > discovered something really odd. I tested the two programs in
> > > question
> > > > > > under
> > > > > > > KMotionCNC, and am satisfied the code is correct - Under
> KMotionCNC,
> > > > > they
> > > > > > > both execute correctly first time, every time, without fail.
> But,
> > > run
> > > > > them
> > > > > > > under my app, using the few lines of code posted last night, and
> the
> > > > > > threads
> > > > > > > start, may, or may not, make the first move, then go out to
> lunch.
> > > > > KMotion
> > > > > > > confirms the threads remain running long after they should have
> > > > > > terminated,
> > > > > > > so they seem to be stuck waiting for..... something. Now, here's
> the
> > > > > > bizarre
> > > > > > > part - If I open KMotionCNC - I don't do anything else, just
> open
> > > the
> > > > > app
> > > > > > -
> > > > > > > the thread immediately picks up and runs to completion
> correctly! If
> > > I
> > > > > > just
> > > > > > > leave KMotionCNC running alongside my app, both DSP programs
> work
> > > > > > perfectly
> > > > > > > every time. In addition, one of them uses a MsgBox to give a
> message
> > > > to
> > > > > > the
> > > > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> > > MsgBox
> > > > > does
> > > > > > > not appear UNTIL KMotionCNC get focus, even though the DSP
> thread
> > > was
> > > > > > > launched from MY app!
> > > > > > >
> > > > > > > What is going on here? What is KMotionCNC doing that affects my
> DSP
> > > > > > programs
> > > > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC,
> when
> > > it
> > > > > did
> > > > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> > > that's
> > > > > > > filling up and blocking communications? I'm at a total loss
> here...
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@...> wrote:
>
> Ray,
>
>
>
> As far as your code goes, I would be looking with an non-judgmental eye and
> with the only goal of finding your problem.
>
>
>
>
>
> Before that , you could try to surround any calls to the KM_Controller
> instance with a lock clause. This will allow only one thread at a time to
> access the controller object.
>
>
>
> Example::
>
>
>
> lock(_Controller)
>
> {
>
> var status = _Controller.WriteLineReadLine("Version");
>
>
>
> var status2 = _Controller.WriteLineReadLine("Version");
>
> }
>
>
>
> Basically, any function you are using the KM_Controller instance in may need
> to be placed in a lock.
>
>
>
> Example2::
>
>
>
> Public void MyUpdatingOrCommandingFunction(args….)
>
> {
>
> lock(_Controller)
>
> {
>
> //Do stuff with your controller here
>
> }
>
> }
>
>
>
>
>
> Try this and let me know if it helps. It is making sense to me that the
> KM_Controller is not Thread safe as it is maintaining pointer references….
> I never ran into it on MM as it never accesses the GUI thread.
>
>
>
> -Brad Murry
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of himykabibble
> Sent: Thursday, January 26, 2012 9:14 PM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
>
>
>
>
>
> Brad,
>
> I'd be happy to send you my code, if you promise not to laugh too hard....
> But perhaps a simple example:
>
> My BackgroundWorker Thread needs to do UpdateStatus, and read things like
> current tool, spindle RPM, and a number of other things. Those are currently
> be done in the BackgroundWorker thread by direct calls to my KM_Controller.
>
> Some of the Button Click handlers also need to access things in
> KM_Controller. For example, the SpindleCW button needs to set two I/Os, and
> run a DSP program to set the PWM. For this, the ButtonClick handler calls a
> method in my dotNet "gasket" that handles all this.
>
> So, My KM_Controller is currently getting called by both the UI thread, and
> the BackgroundWorker thread, which I assume is not a good idea. Would it not
> be better to have only one thread talking the KM_Controller? If so, should I
> move all calls from the BackgroundWorker thread to the UI thread, or
> vice-versa. Or perhaps there's another/better option?
>
> I looked through your HTML app code, but you don't seem to be dealing with
> that problem yet, since it appears to me only the DROs are actually
> functional, and their operation is straight-forward (though I note you are
> making calls directly to dotrNet from the BackgroundWorker DoWork method).
>
> Regards,
> Ray L.
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> Brad Murry <bradodarb@> wrote:
> >
> > Hello Ray,
> >
> >
> >
> > I would probably need to see some code to be much help.
> >
> >
> >
> > Brad Murry
> >
> >
> >
> > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 8:57 PM
> > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > I've got this working pretty well now, with a few exceptions. But I'm not
> > clear on the right way to handle communications with dotNet. My UI update
> > thread needs to access various dotNet data to create the updates. Right
> now,
> > I'm doing those accesses in the DoWork method, creating an object that
> > contains the UI status, then tossing that over to the UI thread to update
> > the controls. But, the UI thread also needs to access dotNet when things
> > like button events occur. Should I push ALL dotNet accesses to the UI
> > thread? Or is there a better way?
> >
> > Right now, something I've done has made the hangs much worse. I'm getting
> > pretty regular hangs in the DLL, without disconnects, and also can't seem
> to
> > get the BackgroundWorker thread to exit. It stops updating the display,
> but
> > doesn't exit.
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > "himykabibble" <jagboy@> wrote:
> > >
> > > Brad,
> > >
> > > Well, I moved the display updates to a BackgroundWorker thread by
> > plagiarizing what you do in your HTML app. It was relatively painless,
> but,
> > surprisingly, didn't really make any perceptible difference in terms of
> > display update performance. It also, not surprisingly, introduced a couple
> > of minor bugs. I have yet to get it to reliably close cleanly. On the
> > FormClosing event, I do a CancelAsync, followed by a Sleep(250), but I
> still
> > sometimes get a null reference error in UpdateDocument when Dispose is
> > called. Not sure I understand why that's happening.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > > >
> > > > The only thing I will add at this point is try it and you will see.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > I will add that MM uses a multi-threading model, has a lot more
> > rendering
> > > > going on that a winforms app, also does openGL toolpath display and I
> > can
> > > > see out to 4-5 decimals changing smoothly during feed moves.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Nowadays any non-trivial app requires multi-threading.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > -Brad
> > > >
> > > >
> > > >
> > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > > Behalf Of himykabibble
> > > > Sent: Wednesday, January 25, 2012 8:59 PM
> > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Brad,
> > > >
> > > > Here's where I keep getting stuck - I believe the bulk of the display
> > update
> > > > time is getting the information from dotNet, not actually updating the
> > > > controls. I already update the DROs more often than the other
> controls,
> > by
> > > > just doing the DROs on every timer tick, and the others on alternate
> > ticks.
> > > > How will another thread improve performance, if the bottleneck is
> > getting
> > > > the update data (which comes primarily from MainStatus), particularly
> > since
> > > > I have to go through an invoke to modify each control?
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > First off, you never want to have too many threads running,
> > technically
> > > > you
> > > > > can only have one run per core and anything after that is going to
> be
> > time
> > > > > slicing.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > If I was making a small lightweight winforms app in .net3.5(like the
> > HTML
> > > > > controller ;-) ), I would/am use/ing the invoke methods I outlined
> > > > earlier.
> > > > >
> > > > >
> > > > >
> > > > > Inside of it, I basically have an endless loop running on a separate
> > > > > worker thread using the simple BackgroundWorker class. The endless
> > loop
> > > > > sleeps every 100ms and I have the DRO's updating on that time slice.
> > > > Within
> > > > > the loop I also have a counter that I increment/reset every 5 cycles
> > and
> > > > > when that happens I update the less important items.
> > > > >
> > > > >
> > > > >
> > > > > Very basic setup that only uses one additional thread that updates
> the
> > > > DRO's
> > > > > 1/10th a second and then things like LED's, enable status, etc… get
> > > > updated
> > > > > every ½ a second.
> > > > >
> > > > >
> > > > >
> > > > > I will re-upload my source so you can see how it works.
> > > > >
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 6:49 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > I'm not changing to WPF at this late stage of the game! :-)
> > > > >
> > > > > I can see how I could use parallel threads to make the display
> updates
> > > > more
> > > > > efficient (launch separate threads to update all the DROs, and other
> > > > > controls). I assume the wonders of .NET will deal with all the
> > concurrency
> > > > > issues that could create in accessing especially dotNet objects? I
> > just
> > > > > checked and my update loop is running only about 5X/second right
> now,
> > > > though
> > > > > GUI response is generally not bad. It's mostly the DRO updates that
> > really
> > > > > need to be sped up.
> > > > >
> > > > > How would you do it?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > > Absolutely, you can push from wherever, but you will need to pass
> a
> > > > > > reference to a control you are using(best bet is the main window)
> to
> > > > your
> > > > > > middle layer.
> > > > > >
> > > > > >
> > > > > >
> > > > > > If you used WPF you would not need to maintain a reference to any
> > > > control
> > > > > as
> > > > > > you could walk up the tree to the current Dispatcher.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > On
> > > > > > Behalf Of himykabibble
> > > > > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Brad,
> > > > > >
> > > > > > Sorry - too many projects, too many people.... :-)
> > > > > >
> > > > > > I have a layer between my GUI and dotNet, to keep the GUI "clean"
> > and
> > > > > > high-level. All communications passes through that layer, and it
> > also
> > > > > allows
> > > > > > me to pull dotNet out, and replace the gasket with a simulator, to
> > test
> > > > > the
> > > > > > GUI stand-alone, and force all the possible states.
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > >
> > > > > > > Who you calling Gary? ;)
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Clarify KM"gasket" please.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > On
> > > > > > > Behalf Of himykabibble
> > > > > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre)
> Problem...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Gary,
> > > > > > >
> > > > > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> > > > assume
> > > > > > that
> > > > > > > could be used to push GUI updates from my KM "gasket" when
> > something
> > > > > > > changes, rather than pulling them from the main app, right?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > > >
> > > > > > > > Ray,
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > I would ditch the timer as well, using a service thread to
> > interact
> > > > > with
> > > > > > > the
> > > > > > > > kflop will be much smoother.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Instead of running your updates via your timer's callback you
> > can
> > > > > either
> > > > > > > use
> > > > > > > > the BackgroundWorker or an Async Delegate or parallel task if
> > using
> > > > > > > .net4.0
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Parallel tasks are best because the will automagically load
> your
> > cpu
> > > > > > usage
> > > > > > > > based on how many cores are available, etc.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Background workers are pretty easy to use and have a
> > comprehensive
> > > > use
> > > > > > > > model.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are
> > easy
> > > > to
> > > > > > use
> > > > > > > to
> > > > > > > > and easy to read.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Whichever method you use, you will need to Invoke/Dispatch
> your
> > > > > control
> > > > > > > > updates when using Winforms/WPF respectively.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > It looks like you are using winforms, so here is a quick
> > > > > pseudo-example
> > > > > > > > where I am using a common method that takes an Action as a
> > parameter
> > > > > and
> > > > > > > > decides whether to invoke or not::
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > public void UpdateDocument(Action action)
> > > > > > > >
> > > > > > > > {
> > > > > > > >
> > > > > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call
> is
> > > > > > > > coming from a thread other than the GUI
> > > > > > > >
> > > > > > > > {
> > > > > > > >
> > > > > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > > > > thread
> > > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > > else
> > > > > > > >
> > > > > > > > {
> > > > > > > >
> > > > > > > > action();//Came from the same thread as the GUI, so no
> > > > > > > > invocation required
> > > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > > }
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > In the updating method of whichever threading model you chose,
> > you
> > > > can
> > > > > > use
> > > > > > > > the above method like so::
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > UpdateDocument(new Action(delegate()
> > > > > > > >
> > > > > > > > {
> > > > > > > >
> > > > > > > > //Put your control updating code here.
> > > > > > > >
> > > > > > > > //Example:
> > > > > > > >
> > > > > > > > lblXaxisDest.Text =
> > _AxisContainer["X"].ActualPosition.ToString();
> > > > > > > >
> > > > > > > > }));
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -Brad Murry
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > [mailto:DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > > On
> > > > > > > > Behalf Of himykabibble
> > > > > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > > > > To: DynoMotion@yahoogroups.com
> <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> <mailto:DynoMotion%40yahoogroups.com>
> > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > So, I've been exercising my app on the machine, and for the
> most
> > > > > parts,
> > > > > > > > things are working OK, though it seems a bit "sluggish" to me.
> > For
> > > > > > > example,
> > > > > > > > when I single-step, it takes a good 1/2 second or more to
> > execute a
> > > > > line
> > > > > > > of
> > > > > > > > G-code containing nothing more than a single comment. When
> > running,
> > > > > the
> > > > > > > DROs
> > > > > > > > update in significant increments, rather than the relatively
> > smooth
> > > > > > > updates
> > > > > > > > I'm accustomed to with Mach3. I'm polling status at roughly
> > 100mSec,
> > > > > so
> > > > > > I
> > > > > > > > would expect it to appear smoother. Could still be problems in
> > my
> > > > > code,
> > > > > > so
> > > > > > > > none of this concerns me at all at this early stage of the
> game.
> > > > > > > >
> > > > > > > > However, in working on the problem of the mis-executing DSP
> > threads,
> > > > > > I've
> > > > > > > > discovered something really odd. I tested the two programs in
> > > > question
> > > > > > > under
> > > > > > > > KMotionCNC, and am satisfied the code is correct - Under
> > KMotionCNC,
> > > > > > they
> > > > > > > > both execute correctly first time, every time, without fail.
> > But,
> > > > run
> > > > > > them
> > > > > > > > under my app, using the few lines of code posted last night,
> and
> > the
> > > > > > > threads
> > > > > > > > start, may, or may not, make the first move, then go out to
> > lunch.
> > > > > > KMotion
> > > > > > > > confirms the threads remain running long after they should
> have
> > > > > > > terminated,
> > > > > > > > so they seem to be stuck waiting for..... something. Now,
> here's
> > the
> > > > > > > bizarre
> > > > > > > > part - If I open KMotionCNC - I don't do anything else, just
> > open
> > > > the
> > > > > > app
> > > > > > > -
> > > > > > > > the thread immediately picks up and runs to completion
> > correctly! If
> > > > I
> > > > > > > just
> > > > > > > > leave KMotionCNC running alongside my app, both DSP programs
> > work
> > > > > > > perfectly
> > > > > > > > every time. In addition, one of them uses a MsgBox to give a
> > message
> > > > > to
> > > > > > > the
> > > > > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> > > > MsgBox
> > > > > > does
> > > > > > > > not appear UNTIL KMotionCNC get focus, even though the DSP
> > thread
> > > > was
> > > > > > > > launched from MY app!
> > > > > > > >
> > > > > > > > What is going on here? What is KMotionCNC doing that affects
> my
> > DSP
> > > > > > > programs
> > > > > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC,
> > when
> > > > it
> > > > > > did
> > > > > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> > > > that's
> > > > > > > > filling up and blocking communications? I'm at a total loss
> > here...
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "himykabibble" <jagboy@...> wrote:
>
> Brad,
>
> Thanks. I'll give that a shot, and report back - shouldn't take too long. I assume I must surround *all* KM accesses with locks for them to be effective?
>
> "I never ran into it on MM as it never accesses the GUI thread." - How did you avoid it? Am I just doing a lot more display updating with controller data than you are?
>
> Regards,
> Ray L.
>
>
> --- In DynoMotion@yahoogroups.com, Brad Murry <bradodarb@> wrote:
> >
> > Ray,
> >
> >
> >
> > As far as your code goes, I would be looking with an non-judgmental eye and
> > with the only goal of finding your problem.
> >
> >
> >
> >
> >
> > Before that , you could try to surround any calls to the KM_Controller
> > instance with a lock clause. This will allow only one thread at a time to
> > access the controller object.
> >
> >
> >
> > Example::
> >
> >
> >
> > lock(_Controller)
> >
> > {
> >
> > var status = _Controller.WriteLineReadLine("Version");
> >
> >
> >
> > var status2 = _Controller.WriteLineReadLine("Version");
> >
> > }
> >
> >
> >
> > Basically, any function you are using the KM_Controller instance in may need
> > to be placed in a lock.
> >
> >
> >
> > Example2::
> >
> >
> >
> > Public void MyUpdatingOrCommandingFunction(args….)
> >
> > {
> >
> > lock(_Controller)
> >
> > {
> >
> > //Do stuff with your controller here
> >
> > }
> >
> > }
> >
> >
> >
> >
> >
> > Try this and let me know if it helps. It is making sense to me that the
> > KM_Controller is not Thread safe as it is maintaining pointer references….
> > I never ran into it on MM as it never accesses the GUI thread.
> >
> >
> >
> > -Brad Murry
> >
> > From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> > Behalf Of himykabibble
> > Sent: Thursday, January 26, 2012 9:14 PM
> > To: DynoMotion@yahoogroups.com
> > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> >
> >
> >
> >
> >
> > Brad,
> >
> > I'd be happy to send you my code, if you promise not to laugh too hard....
> > But perhaps a simple example:
> >
> > My BackgroundWorker Thread needs to do UpdateStatus, and read things like
> > current tool, spindle RPM, and a number of other things. Those are currently
> > be done in the BackgroundWorker thread by direct calls to my KM_Controller.
> >
> > Some of the Button Click handlers also need to access things in
> > KM_Controller. For example, the SpindleCW button needs to set two I/Os, and
> > run a DSP program to set the PWM. For this, the ButtonClick handler calls a
> > method in my dotNet "gasket" that handles all this.
> >
> > So, My KM_Controller is currently getting called by both the UI thread, and
> > the BackgroundWorker thread, which I assume is not a good idea. Would it not
> > be better to have only one thread talking the KM_Controller? If so, should I
> > move all calls from the BackgroundWorker thread to the UI thread, or
> > vice-versa. Or perhaps there's another/better option?
> >
> > I looked through your HTML app code, but you don't seem to be dealing with
> > that problem yet, since it appears to me only the DROs are actually
> > functional, and their operation is straight-forward (though I note you are
> > making calls directly to dotrNet from the BackgroundWorker DoWork method).
> >
> > Regards,
> > Ray L.
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> > Brad Murry <bradodarb@> wrote:
> > >
> > > Hello Ray,
> > >
> > >
> > >
> > > I would probably need to see some code to be much help.
> > >
> > >
> > >
> > > Brad Murry
> > >
> > >
> > >
> > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ]
> > On
> > > Behalf Of himykabibble
> > > Sent: Thursday, January 26, 2012 8:57 PM
> > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > >
> > >
> > >
> > >
> > >
> > > Brad,
> > >
> > > I've got this working pretty well now, with a few exceptions. But I'm not
> > > clear on the right way to handle communications with dotNet. My UI update
> > > thread needs to access various dotNet data to create the updates. Right
> > now,
> > > I'm doing those accesses in the DoWork method, creating an object that
> > > contains the UI status, then tossing that over to the UI thread to update
> > > the controls. But, the UI thread also needs to access dotNet when things
> > > like button events occur. Should I push ALL dotNet accesses to the UI
> > > thread? Or is there a better way?
> > >
> > > Right now, something I've done has made the hangs much worse. I'm getting
> > > pretty regular hangs in the DLL, without disconnects, and also can't seem
> > to
> > > get the BackgroundWorker thread to exit. It stops updating the display,
> > but
> > > doesn't exit.
> > >
> > > Regards,
> > > Ray L.
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > "himykabibble" <jagboy@> wrote:
> > > >
> > > > Brad,
> > > >
> > > > Well, I moved the display updates to a BackgroundWorker thread by
> > > plagiarizing what you do in your HTML app. It was relatively painless,
> > but,
> > > surprisingly, didn't really make any perceptible difference in terms of
> > > display update performance. It also, not surprisingly, introduced a couple
> > > of minor bugs. I have yet to get it to reliably close cleanly. On the
> > > FormClosing event, I do a CancelAsync, followed by a Sleep(250), but I
> > still
> > > sometimes get a null reference error in UpdateDocument when Dispose is
> > > called. Not sure I understand why that's happening.
> > > >
> > > > Regards,
> > > > Ray L.
> > > >
> > > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ,
> > > Brad Murry <bradodarb@> wrote:
> > > > >
> > > > > The only thing I will add at this point is try it and you will see.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > I will add that MM uses a multi-threading model, has a lot more
> > > rendering
> > > > > going on that a winforms app, also does openGL toolpath display and I
> > > can
> > > > > see out to 4-5 decimals changing smoothly during feed moves.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Nowadays any non-trivial app requires multi-threading.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > -Brad
> > > > >
> > > > >
> > > > >
> > > > > From: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > [mailto:DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com> ]
> > > On
> > > > > Behalf Of himykabibble
> > > > > Sent: Wednesday, January 25, 2012 8:59 PM
> > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Brad,
> > > > >
> > > > > Here's where I keep getting stuck - I believe the bulk of the display
> > > update
> > > > > time is getting the information from dotNet, not actually updating the
> > > > > controls. I already update the DROs more often than the other
> > controls,
> > > by
> > > > > just doing the DROs on every timer tick, and the others on alternate
> > > ticks.
> > > > > How will another thread improve performance, if the bottleneck is
> > > getting
> > > > > the update data (which comes primarily from MainStatus), particularly
> > > since
> > > > > I have to go through an invoke to modify each control?
> > > > >
> > > > > Regards,
> > > > > Ray L.
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > Brad Murry <bradodarb@> wrote:
> > > > > >
> > > > > >
> > > > > > First off, you never want to have too many threads running,
> > > technically
> > > > > you
> > > > > > can only have one run per core and anything after that is going to
> > be
> > > time
> > > > > > slicing.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > If I was making a small lightweight winforms app in .net3.5(like the
> > > HTML
> > > > > > controller ;-) ), I would/am use/ing the invoke methods I outlined
> > > > > earlier.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Inside of it, I basically have an endless loop running on a separate
> > > > > > worker thread using the simple BackgroundWorker class. The endless
> > > loop
> > > > > > sleeps every 100ms and I have the DRO's updating on that time slice.
> > > > > Within
> > > > > > the loop I also have a counter that I increment/reset every 5 cycles
> > > and
> > > > > > when that happens I update the less important items.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Very basic setup that only uses one additional thread that updates
> > the
> > > > > DRO's
> > > > > > 1/10th a second and then things like LED's, enable status, etc… get
> > > > > updated
> > > > > > every ½ a second.
> > > > > >
> > > > > >
> > > > > >
> > > > > > I will re-upload my source so you can see how it works.
> > > > > >
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > On
> > > > > > Behalf Of himykabibble
> > > > > > Sent: Wednesday, January 25, 2012 6:49 PM
> > > > > > To: DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Brad,
> > > > > >
> > > > > > I'm not changing to WPF at this late stage of the game! :-)
> > > > > >
> > > > > > I can see how I could use parallel threads to make the display
> > updates
> > > > > more
> > > > > > efficient (launch separate threads to update all the DROs, and other
> > > > > > controls). I assume the wonders of .NET will deal with all the
> > > concurrency
> > > > > > issues that could create in accessing especially dotNet objects? I
> > > just
> > > > > > checked and my update loop is running only about 5X/second right
> > now,
> > > > > though
> > > > > > GUI response is generally not bad. It's mostly the DRO updates that
> > > really
> > > > > > need to be sped up.
> > > > > >
> > > > > > How would you do it?
> > > > > >
> > > > > > Regards,
> > > > > > Ray L.
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > >
> > > > > > > Absolutely, you can push from wherever, but you will need to pass
> > a
> > > > > > > reference to a control you are using(best bet is the main window)
> > to
> > > > > your
> > > > > > > middle layer.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > If you used WPF you would not need to maintain a reference to any
> > > > > control
> > > > > > as
> > > > > > > you could walk up the tree to the current Dispatcher.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > -Brad
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > On
> > > > > > > Behalf Of himykabibble
> > > > > > > Sent: Wednesday, January 25, 2012 6:14 PM
> > > > > > > To: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com> <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre) Problem...
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Brad,
> > > > > > >
> > > > > > > Sorry - too many projects, too many people.... :-)
> > > > > > >
> > > > > > > I have a layer between my GUI and dotNet, to keep the GUI "clean"
> > > and
> > > > > > > high-level. All communications passes through that layer, and it
> > > also
> > > > > > allows
> > > > > > > me to pull dotNet out, and replace the gasket with a simulator, to
> > > test
> > > > > > the
> > > > > > > GUI stand-alone, and force all the possible states.
> > > > > > >
> > > > > > > Regards,
> > > > > > > Ray L.
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > > >
> > > > > > > > Who you calling Gary? ;)
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Clarify KM"gasket" please.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > -Brad Murry
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > > On
> > > > > > > > Behalf Of himykabibble
> > > > > > > > Sent: Wednesday, January 25, 2012 5:34 PM
> > > > > > > > To: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > Subject: [DynoMotion] Re: Houston, We Have A (Bizarre)
> > Problem...
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Gary,
> > > > > > > >
> > > > > > > > I noted the " _GuiHost.Parent.Invoke(action)" in your example. I
> > > > > assume
> > > > > > > that
> > > > > > > > could be used to push GUI updates from my KM "gasket" when
> > > something
> > > > > > > > changes, rather than pulling them from the main app, right?
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > > Ray L.
> > > > > > > >
> > > > > > > > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > <mailto:DynoMotion%40yahoogroups.com> ,
> > > > > > > > Brad Murry <bradodarb@> wrote:
> > > > > > > > >
> > > > > > > > > Ray,
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I would ditch the timer as well, using a service thread to
> > > interact
> > > > > > with
> > > > > > > > the
> > > > > > > > > kflop will be much smoother.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Instead of running your updates via your timer's callback you
> > > can
> > > > > > either
> > > > > > > > use
> > > > > > > > > the BackgroundWorker or an Async Delegate or parallel task if
> > > using
> > > > > > > > .net4.0
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Parallel tasks are best because the will automagically load
> > your
> > > cpu
> > > > > > > usage
> > > > > > > > > based on how many cores are available, etc.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Background workers are pretty easy to use and have a
> > > comprehensive
> > > > > use
> > > > > > > > > model.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Async delegates(using beginInvoke(IAsyncCallback, object) are
> > > easy
> > > > > to
> > > > > > > use
> > > > > > > > to
> > > > > > > > > and easy to read.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Whichever method you use, you will need to Invoke/Dispatch
> > your
> > > > > > control
> > > > > > > > > updates when using Winforms/WPF respectively.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > It looks like you are using winforms, so here is a quick
> > > > > > pseudo-example
> > > > > > > > > where I am using a common method that takes an Action as a
> > > parameter
> > > > > > and
> > > > > > > > > decides whether to invoke or not::
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > public void UpdateDocument(Action action)
> > > > > > > > >
> > > > > > > > > {
> > > > > > > > >
> > > > > > > > > if (_GuiHost.Parent.InvokeRequired)//Tests to see if the call
> > is
> > > > > > > > > coming from a thread other than the GUI
> > > > > > > > >
> > > > > > > > > {
> > > > > > > > >
> > > > > > > > > _GuiHost.Parent.Invoke(action);//Merge action into the GUI
> > > > > > > > > thread
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > else
> > > > > > > > >
> > > > > > > > > {
> > > > > > > > >
> > > > > > > > > action();//Came from the same thread as the GUI, so no
> > > > > > > > > invocation required
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > > }
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > In the updating method of whichever threading model you chose,
> > > you
> > > > > can
> > > > > > > use
> > > > > > > > > the above method like so::
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > UpdateDocument(new Action(delegate()
> > > > > > > > >
> > > > > > > > > {
> > > > > > > > >
> > > > > > > > > //Put your control updating code here.
> > > > > > > > >
> > > > > > > > > //Example:
> > > > > > > > >
> > > > > > > > > lblXaxisDest.Text =
> > > _AxisContainer["X"].ActualPosition.ToString();
> > > > > > > > >
> > > > > > > > > }));
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > -Brad Murry
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > [mailto:DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > <mailto:DynoMotion%40yahoogroups.com> ]
> > > > > > > > On
> > > > > > > > > Behalf Of himykabibble
> > > > > > > > > Sent: Wednesday, January 25, 2012 3:42 PM
> > > > > > > > > To: DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>
> > > <mailto:DynoMotion%40yahoogroups.com>
> > <mailto:DynoMotion%40yahoogroups.com>
> > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > <mailto:DynoMotion%40yahoogroups.com>
> > > > > > > > > Subject: [DynoMotion] Houston, We Have A (Bizarre) Problem...
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > So, I've been exercising my app on the machine, and for the
> > most
> > > > > > parts,
> > > > > > > > > things are working OK, though it seems a bit "sluggish" to me.
> > > For
> > > > > > > > example,
> > > > > > > > > when I single-step, it takes a good 1/2 second or more to
> > > execute a
> > > > > > line
> > > > > > > > of
> > > > > > > > > G-code containing nothing more than a single comment. When
> > > running,
> > > > > > the
> > > > > > > > DROs
> > > > > > > > > update in significant increments, rather than the relatively
> > > smooth
> > > > > > > > updates
> > > > > > > > > I'm accustomed to with Mach3. I'm polling status at roughly
> > > 100mSec,
> > > > > > so
> > > > > > > I
> > > > > > > > > would expect it to appear smoother. Could still be problems in
> > > my
> > > > > > code,
> > > > > > > so
> > > > > > > > > none of this concerns me at all at this early stage of the
> > game.
> > > > > > > > >
> > > > > > > > > However, in working on the problem of the mis-executing DSP
> > > threads,
> > > > > > > I've
> > > > > > > > > discovered something really odd. I tested the two programs in
> > > > > question
> > > > > > > > under
> > > > > > > > > KMotionCNC, and am satisfied the code is correct - Under
> > > KMotionCNC,
> > > > > > > they
> > > > > > > > > both execute correctly first time, every time, without fail.
> > > But,
> > > > > run
> > > > > > > them
> > > > > > > > > under my app, using the few lines of code posted last night,
> > and
> > > the
> > > > > > > > threads
> > > > > > > > > start, may, or may not, make the first move, then go out to
> > > lunch.
> > > > > > > KMotion
> > > > > > > > > confirms the threads remain running long after they should
> > have
> > > > > > > > terminated,
> > > > > > > > > so they seem to be stuck waiting for..... something. Now,
> > here's
> > > the
> > > > > > > > bizarre
> > > > > > > > > part - If I open KMotionCNC - I don't do anything else, just
> > > open
> > > > > the
> > > > > > > app
> > > > > > > > -
> > > > > > > > > the thread immediately picks up and runs to completion
> > > correctly! If
> > > > > I
> > > > > > > > just
> > > > > > > > > leave KMotionCNC running alongside my app, both DSP programs
> > > work
> > > > > > > > perfectly
> > > > > > > > > every time. In addition, one of them uses a MsgBox to give a
> > > message
> > > > > > to
> > > > > > > > the
> > > > > > > > > user. If I have KMotionCNC minimized or otherwise hidden, this
> > > > > MsgBox
> > > > > > > does
> > > > > > > > > not appear UNTIL KMotionCNC get focus, even though the DSP
> > > thread
> > > > > was
> > > > > > > > > launched from MY app!
> > > > > > > > >
> > > > > > > > > What is going on here? What is KMotionCNC doing that affects
> > my
> > > DSP
> > > > > > > > programs
> > > > > > > > > in such a way? Why is the MsgBox seemingly tied to KMotionCNC,
> > > when
> > > > > it
> > > > > > > did
> > > > > > > > > NOT launch the threads? Is there some buffer or FIFO somewhere
> > > > > that's
> > > > > > > > > filling up and blocking communications? I'm at a total loss
> > > here...
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > > Ray L.
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>